1. Field of the Invention
The present invention generally relates to automation systems, and more particularly, to a method and apparatus for automating equipment used in a microelectronic manufacturing process.
2. Description of Related Art
Automation systems have been used in a variety of microelectronic manufacturing processes such as in processes to manufacture semiconductor devices, flat panel devices and disk drive devices. For example, in a typical semiconductor manufacturing facility (Fab), semiconductor fabrication equipment and metrology equipment are used to fabricate and test semiconductor devices located on silicon wafers. In the past, the manual operation of equipment in a Fab has been gradually replaced by an automated process to alleviate costly semiconductor manufacturing problems associated with non-automated, manual operations.
Manual operation of equipment in a Fab has numerous limitations. These problems are normally associated with human error in the handling of wafers grouped in lots that result in misprocessing due to human error and fatigue. The problems are also associated with the improper interaction with many external information systems, as well as devices, that must all be synchronized for efficient manufacturing production. For example, errors in the routing or the processing of wafer lots are costly and can be the largest problem area in semiconductor manufacturing. A reduction in the occurrence of wrong lots being loaded into process equipment or selecting the wrong process recipes is needed to prevent errors in routing and processing.
A second problem area in manually operating equipment is that errors occur during the manual data collection process. Manufacturing operators often manually enter data at each process step and interact with the Manufacturing Execution System (MES) dozens of times for each individual wafer lot being processed. Each time an operator manually enters data into the MES, errors can be inadvertently introduced. These errors can compromise the integrity of the MES database as well as the validity of manufacturing decisions based on the data contained therein. To improve manufacturing quality, sampling of wafer lots must be performed automatically since the amount of sampling needed is too large of an amount for manual operators to support. In addition, this constant interaction with the MES slows the production process and decreases effective productivity due to the inefficient use of an operator""s time. Furthermore, the amount of data that an operator can manually input is limited. With processing becoming more complicated, manual operation has exceeded human capabilities.
A third problem area addressed by semiconductor manufacturing automation is the control of wafer lot location and identification during the manufacturing process. Tracking and identifying thousands of lots throughout a Fab is a time consuming and error-prone process. This is especially true when multiple lots are located and processed simultaneously, using fewer ports on equipment for loading and unloading the lots. Wrong identification of lots may result in the complete loss of the lot, which, in turn, results in delays of lots to customers. Automation processes are able to interact with intelligent tracking devices normally placed on individual lots to exchange control and tracking information. The semiconductor industry has thus moved to automated semiconductor manufacturing processes to alleviate these problems of manually operating a Fab.
While automated semiconductor processes have alleviated the material handling problems described above, these automated processes are costly, time consuming, have limited reusability and limited extensibility. Present automation processes are costly due to the amount of time and resources needed to characterize new equipment and then develop a custom (close fitting) automation software or a general purpose (loose fitting) automation software to automate the equipment in a Fab. In either case, a large amount of. effort is spent in rigorously testing the automation software (e.g. testing of 40-60 software programs (one for each equipment) in the case of the custom software and one giant software program (for the general purpose software). In addition, any code changes in either the custom or general purpose software has global system ramifications that must be performed by experienced programmers. Furthermore, any changes to the code requires regression testing on all equipment types to be certified for production release. The software release management thus becomes very critical, prone to errors and time consuming. The use of the custom automation software and/or general purpose software to characterize new semiconductor equipment is defined as the xe2x80x9cCode Model.xe2x80x9d
A problem with the Code Model is the excessive amount of time needed to prepare the computer code to characterize a new piece of equipment. A programmer may need approximately two to three weeks of total programming time to characterize a single piece of equipment. Since a conventional Fab may have approximately 40 to 60 different types of equipment that must be characterized, the amount of time to characterize all the new equipment in the Fab results in a costly amount of programming time. In addition, a significant amount of equipment downtime is incurred as the equipment is being characterized that negatively affects production.
In addition to the excessive amount of time needed to characterize new equipment using the Code Model, a significant amount of time is also needed to make changes to the custom and/or general purpose software to correspond to software revisions made to existing equipment by the manufacturer. Furthermore, throughout the equipment""s use in a Fab, the process flows for fabricating a semiconductor device may change over time or other parameters in the fabrication may change. Thus, for example, should a new process step be added to the process flow for fabricating a certain semiconductor device, or should the characterization need to be adjusted for a piece of equipment, the Code Model requires that a build of the custom and/or general purpose software be performed repeatedly. Repeated builds take a substantial amount of programming and testing time as well as equipment downtime to accomplish. There is therefore a need to reduce the costs associated with updating the custom and/or general purpose software, as well as costs incurred due to downtime of the equipment. The costs incurred with the Code Model are associated with the limited reusability of the custom and/or general purpose software since that software must be updated when new process steps or additional characterization is needed. Likewise, extensibility of an automation process utilizing the Code Model is limited due to the additional programming needed.
An attempted solution to the Code Model problem has been to move towards an object-oriented solution. A component model approach (xe2x80x9cComponent Modelxe2x80x9d) has been proposed to reuse objects, rather than code as in the Code Model, to the extent possible by treating the code objects as components. This approach would use, for example, Component Object Modeling(COM) paradigm, which is well known in the art, to improve the reusability of defined components. The Component Model, however, is limited in that it requires a substantial amount of reprogramming, much like the Code Model, in order to change the semiconductor manufacturing process. Furthermore, the Component Model requires a programmer to understand COM, which is not generally known. Thus, the Component Model also suffers from high cost due to limited automation process reusability and extensibility. Further, the automation software developed using the Component Model would be limited to a particular piece of equipment. Thus, there would be as many different programs as there are equipment types in a Fab. Still further, it is difficult to maintain and support so many variations of the code.
Various computer architecture and methodologies, separate from the Code and Component Models, have also been used to achieve and improve automation processes. For example, factory automation has moved from a two-tiered client/server architecture to a three-tiered architecture to provide a more efficient automation process. Clients are defined as computational entities that request service resources, while servers are resource entities that respond to service requests. Thus, servers provide services and other resources to clients which consume them.
In a traditional two-tiered client/server architecture, the client communicates directly with one or more database servers or external systems to execute various tasks. The disadvantage of the two-tiered architecture is that either the client or the server contains the business logic, a collection of rules that define the system logic. This reduces the reusability of the client and/or server because, wherever the business logic resides, that portion of the code may not fit into a different business model. Usually, such changes are incompatible with earlier versions of the client, resulting in a fragile application.
These problems with the traditional two-tiered client/server application have been addressed by a three-tiered architecture. The three-tiered architecture partitions the automation process into three logical layers: the user interface layer, the business rules layer and the database access layer. In this architecture, the user interface layer resides on the client. The business logic layer, the database access layer and the database itself reside on the server. The three-tiered architecture makes the application less fragile by further insulating the client from changes in the rest of the application. In other words, the three-tiered client/server architecture reduces application fragility by providing more insulation and separation between layers. The user interface layer communicates only with the business rules layer, rather than the database access layer. The business rules layer, in turn, communicates with the user interface layer on one side and the database access layer on the other. Thus, changes in the database access layer will not affect the user interface layer because the two layers are insulated from each other.
The three-tiered architecture approach is best suited for database applications due to this insulation. However, in a Fab, where services are required to communicate with equipment, as well as other devices and systems, additional tiers are necessary. A need therefore exists for an architecture that incorporates additional tiers for automatic interfacing with semiconductor equipment within the Fab.
In the past, automation processes have used a three-tiered architecture in combination with the Component Model. A configurable state machine was used with reusable components for equipment interface. However, a problem remains in that approach in that one program controlled only one piece of equipment and extensibility was limited because multiple versions of code existed that must all be updated should changes be necessary. Also, changes to a process or equipment often required code level changes that are complicated and time-consuming.
A combination of an object-oriented approach, such as a distributed model, with a multi-tiered architecture approach, has been described by a technology standard for distributed objects known as Common Object Request Broker Architecture (CORBA), developed by a consortium, Object Management Group. In CORBA, clients and servers exist in a distributed environment. Distributed objects are most often deployed in a client/server configuration. Objects may themselves be servers. Rather than differentiate between business logic and data access, the distributed system model simply exposes all functionality of the application as objects, each of which can use any of the services provided by other objects in the system, or even objects in other systems.
CORBA can also blur the distinction between client and server because the client can also create objects that behave in server-like roles. The distributed system architecture thus obtains a high degree of flexibility by encouraging or enforcing the definition of specific component interfaces. The interface of an object specifies to other objects what services are offered by that object and how they are used. As long as the interface of a objects remains constant, that object""s implementation can change dramatically without affecting other objects.
In view of the different models, architectures and distributed environments described above, a need exists for a method of automating a microelectronic manufacturing process that avoids the limitations noted above of prior automation processes and that takes advantage of the distributed object model approach. This needed method must permit speedy configuration of new equipment, reusability of the software to reflect changes to the equipment as well as changes to process steps in the manufacturing process, and provide extensibility to the automation process. There also is a need for one software program suite that automates all types of equipment in a Fab to facilitate software revisions and maintenance. A need further exists to use, as part of an automation system, component technology to enhance extensibility.
The present invention provides a method of automating a microelectronic manufacturing process by configuring an application object that contains the domain knowledge for a piece of equipment. The configuration process is performed by a user in a short amount of time and corresponds to providing characteristics to an automation system of the equipment and external interfaces. After the configuration of the application object has been accomplished, a workflow is implemented by a user by designing the workflow and registering the workflow in a workflow engine. The workflow is designed to represent the manufacturing process. The work flow is then registered in a work flow engine to be executed in order to perform the manufacturing process.
A computer readable medium, having a computer program stored thereon, is also provided so that when the computer program is loaded into a computer system, the computer performs a function of automating a microelectronic manufacturing process by performing the above method. In one embodiment, the computer system is a part of the automation system.
An apparatus is also provided for automating a microelectronic manufacturing process that includes a display device, an interface device and a storage device containing the computer program that performs the method of automating a microelectronic manufacturing process of the present invention. A processing device is also included for executing the computer program.